We’ve looked at literature on various topics on the blog before, such as legacy code or dysfunctions in teams. Team Topologies deals with organizational design and team interaction, wich are also essential for effective software teams. Now you might think this is mainly a topic for managers and organizational developers, but the underlying principles apply to all team members in software development teams.

Team Topologies was released in 2019 and addresses a core problem in modern software development: how can we continuously deliver new features quickly and with high quality?

Team Topologies is best known though for the 4 team types and 3 team interactions that authors Matthew Skelton and Manuel Pais have identified in software companies.

There is no way around Conway’s Law

Conway’s Law is one of the cornerstones on which the book is based. Back in 1968, Mel Conway postulated that organizations that design systems are forced to create a copy of their communication structures. From this follows that team interactions and software architecture have to be considered together.

In order to develop new features sustainably and quickly (Team Topologies uses the wording “rapid flow of changes” here), teams notoriously have to be cross-functional and aligned with separated software modules.

However, it is also important to ensure that communication between teams is consciously limited: If everybody communicates with everyone else, the end result is a monolithic, interwoven system that makes rapid changes difficult - this is also a consequence of Conway’s Law!

Every team can only deal with a certain amount of cognitive load

A second essential point is the book’s focus on cognitive load in teams. Each team can only handle a certain level of cognitive load, and teams and their work must therefore be sized so that this load is not exceeded.

For this, Team Topologies provides heuristics that can help determine if a team has too much cognitive load: When domains are divided into different complexity categories(simple/complex/complex), teams can be responsible for 2-3 simple domains, but should not have several domains of high complexity in their responsibility. If a team is responsible for a complex domain, it should not be responsible for any other domains at all.

Four team topologies and three kinds of team interactions

A main contribution of the book is undoubtedly the identification of the four team topologies and three types of team interactions.

The four team topologies define different types which can be used to obtain a clean team structure in software development organizations:

  • Stream-aligned teams deliver business value by working independently on a stream of topics in a specific domain,

  • Enabling teams consist of specialists for a certain topic and help to bring this knowledge into other teams,

  • Complicated-subsystem teams are responsible for a subsystem that is highly complex and can be managed and deployed separately from the stream-aligned teams,

  • Platform teams provide infrastructure as an “internal product” for stream-aligned teams, which they can use to implement their stories autonomously, i.e. without major cross-team efforts.

Depending on the team type, the following types of interaction between the teams have emerged:

  • Collaboration: One team works closely with another team.

  • X-as-a-service: One team uses the service of another team with as little collaboration as possible.

  • Facilitation: One team helps another team to overcome obstacles.

These types differ in their suitability for different team types. While stream-aligned teams often work in collaboration mode with other teams, albeit usually on a temporary basis, platform teams aim for X-as-a-service interaction. Also, the nature of the interaction may change over time. More important, however, this classification can be used to make the nature of the interaction explicit. This helps avoiding ambiguity and extra work.

What else?

While the team topologies and interactions are certainly the most well-known topics in the book, it contains a few other gems that should also be addressed in detail. We will briefly touch on two such points here:

First, the authors explicitly describe different types of monoliths. When it comes to avoiding them, one often thinks of software that is structured as a monolith. But a monolith can also be present in the build system, in an all-encompassing model (consistency at all costs), or even as a monolithic mindset (when one-size-fits-all is imposed on teams, unnecessarily restricting them in their work).

All these cases can severely result in increased cognitive load in teams, making them unable to work effectively.

Another important topic the book deals can be found in so-called fracture planes: This refers to possible types of boundaries that can be used to modularize software and thus split it up among different teams. Business domains are often used here for a split. Depending on the type of software and the domain, however, other criteria can also be useful, such as compliance, change frequency, risk consideration, and a few more.

Conclusion

Some books give you the impression that its contents could be distilled to one core idea and, when reading on, the book only continues to repeat the same topic over and over again. Team Topologies is not like that at all - this book provides valuable insights from beginning to end. Thus, it can be clearly considered as part of the standard repertoire of modern software literature.

Webinar: Scaling software development as a SaaS company without becoming consumed in the growth process.

The webinar addressed exactly the pain points that are occurring as we grow. With an ever-increasing number of employees on the Dev & Product team, we've had to find out for ourselves how difficult it is to set up a sensible structure that brings out the maximum efficiency and performance in everyone, while also leading to a healthy working atmosphere.
Pascal von Briel, Co-Founder & CPO @ exporto GmbH